The present invention relates generally to the field of data processing systems, methods, and computer program products, and, more particularly, to managing a memory pool.
Data processing systems, methods, and/or computer program products may reserve a portion of memory, which may be referred to as a xe2x80x9cheap,xe2x80x9d for use by a program for the temporary storage of data and/or information whose existence or size may not be able to be determined until the program executes. For example, in object oriented software systems, an instantiation of a class, i.e., an object, may be allocated in the heap. To facilitate access of objects, a xe2x80x9chandlexe2x80x9d may be associated with each object that is allocated in the heap and these handles may also be allocated in the heap. A handle contains a pointer (i e., the address of the associated object in the heap) and information for the object with which it is associated. Thus, programs may reference objects indirectly using the respective handles that are associated therewith rather than referencing the objects directly in the heap. One advantage to this approach is that as objects are relocated in the heap to defragment the heap memory region, only the pointers used by the handles in the heap need be updated.
One example of an object oriented programming language is the Java programming language, which has been developed by Sun Microsystems, Mountain View, Calif. Java is a portable and architecturally neutral language. Java source code is compiled into a machine independent format that may be run on machines configured with a Java runtime system known as a Java Virtual Machine (JVM). The JVM is defined as an imaginary machine that is implemented by emulating a processor through the use of software on a real machine. Accordingly, machines running under diverse operating systems, including UNIX and Windows NT, having a JVM can execute the same Java program.
The JVM uses a heap for allocation of both objects and handles that are associated therewith. To improve the management of the heap memory, the heap may be separated into a handle sub-pool and an object sub-pool. Each sub-pool is typically given a fixed size that when combined comprises the entire heap memory. Unfortunately, dividing the heap into multiple, fixed size sub-pools may result in a lower utilization of the heap memory region. For example, the object sub-pool may run out of space while the handle sub-pool still has space available. Conversely, the handle sub-pool may run out of space while the object sub-pool still has space available. An optimal division of the heap memory between the handle and object sub-pools may be difficult to attain because the optimal division may vary during runtime as Java applications vary their object usage.
In view of the foregoing, there exists a need for improvements in management of memory pools, such as heap memory.
According to embodiments of the present invention, memory pool management may be provided by allocating storage blocks and handles in different parts of a larger memory pool. Two variable size sub-pools may be provided within the memory pool: a storage block sub-pool and a handle sub-pool. Each sub-pool has a variable size and may be allowed to grow until their combined size reaches the size of the memory pool. Both sub-pools may be allowed to grow into the same unused memory space. As a result, improved utilization of the memory pool space may be achieved. When a memory request is received from a program, the storage block sub-pool and handle sub-pool may be enlarged to accommodate the request. A storage block and a handle may be allocated to the program from the storage block and handle sub-pools, respectively.
In accordance with embodiments of the present invention, handles are allocated starting at one end of the memory pool and storage blocks are allocated starting at the other end of the memory pool. Each sub-pool has a variable size and is allowed to grow until their combined size reaches the size of the memory pool. Preferably, a determination is made whether the handle sub-pool contains any deallocated handles before enlarging the size of the handle sub-pool to accommodate a new storage block request. As a result, the present invention may provide for improved utilization of a memory pool. Handles and storage blocks generally have different characteristics: handles are typically small and have a fixed size; storage blocks may vary both in size and usage. By allocating handles and storage blocks in separate, variable sized sub-pools, each data type may be allowed to consume and release memory in accordance with the requirements of a particular application. New handles and storage blocks may be allocated until the memory pool is filled. Inasmuch as the memory pool is shared between handles and storage blocks, the problem of having a full memory pool even though space is still available in one of the sub-pools may be avoided. In addition, the improved utilization of the memory pool may allow for a smaller memory pool size, which conserves memory.
In accordance with further embodiments of the present invention, if there is insufficient memory in the memory pool to grant a storage block request, the memory pool may be examined to determine if there are any storage blocks that are no longer in use. The operation of examining a region in memory and reclaiming unused portions for reuse is often referred to as xe2x80x9cgarbage collection.xe2x80x9d Note that garbage collection may also be implemented as a background process to be performed on a periodic basis. If one or more storage blocks are detected as being no longer in use, these storage block(s) and their associated handle(s) may be deallocated. The storage block sub-pool may then be compacted towards one end of the memory pool to remove the storage blocks that are no longer in use from the storage block sub-pool and to consolidate those storage blocks that are no longer in use into a larger block of available memory in the middle of the memory pool. This compaction of the storage block sub-pool may avoid the problems associated with memory fragmentation.
Because the handles are a fixed size, the handle sub-pool may not suffer from memory fragmentation problems. Handles that are deallocated during garbage collection may be reused. For example, when a new handle is requested, it may be allocated from existing space within the handle sub-pool. Thus, the size of the handle sub-pool grows only when there are no idle (i.e., deallocated) handles available in the handle sub-pool to fulfill a request.
The present invention may, therefore, be used to control utilization of a memory pool through use of variable size sub-pools that are allowed to grow until the memory pool is full. Because of the improved memory pool utilization provided by the present invention, garbage collection may be run less frequently to free up memory in the memory pool. Accordingly, processor resources may be conserved.